Ranges Tabellentyp definieren

Posted on by Enno Wulff

Related Post

Ranges sind eine starke Waffe im SAP im Kampf um zu viele Daten (hach wie poetisch…). Leider gibt es keinen allgemeinen Datentyp RANGES. Im Coding kann ich zwar eine Ranges-Tabelle definieren, aber ich kann dies nicht in Parametern von Methoden oder Funktionsbausteinen verwenden. Hierfür muss ein separater Tabellentyp im Dictionary angelegt werden.

RANGES Definition im Quelltext

Im Quelltext wird eine Ranges-Tabelle üblicherweise auf drei Arten definiert:

  1. SELECT-OPTIONS s_bukrs FOR t001-bukrs.
  2. RANGES r_bukrs FOR t001-bukrs.
  3. DATA r_bukrs TYPE RANGE OF bukrs.

Mit jedem Befehl wird eine interne Tabelle mit folgenden Feldern angelegt:

  • SIGN: Wert einschließen (I = include) oder ausschließen (E = exclude)
  • OPTION: EQ = EQual, BT = BeTween etc.
  • LOW: niedrigster Wert des Intervalls
  • HIGH: höchster Wert des Intervalls (leer, wenn OPTION = EQ)

Bei 1. und 2. wird diese Tabelle mit impliziter Kopfzeile (!) definiert.

Bei 3. muss der Arbeitsbereich separat definiert werden:

DATA s_bukrs LIKE LINE OF r_bukrs.

Namenskonvention

Die Namensgebung bei RANGES-Tabellen finde ich aus folgenden Gründen immer etwas schwierig:

  • Den Prefix R für RANGES benutze ich in der Regel für Objektreferenzen. Eine lokal definierte Objektreferenz heisst dann zum Beispiel LR_GRID. Hier könnte ich mir behelfen, indem ich das Prefix O für Objektreferenz verwende, also LO_GRID.
  • Eine RANGES-Tabelle besteht immer aus der Tabelle selbst und dem zugehörigen Arbeitsbereich. Der Arbeitsbereich kann eine Struktur sein oder aber auch ein strukturiertes Feldsymbol. Dementsprechend müsste der Prefix aus drei Stellen bestehen (Wenn man, so wie ich, jedoch immer einen zweistelligen Prefix hat, dann sieht ein dreistelliger “doof” aus):
    • LTR_BUKRS für eine lokal definierte Ranges-Tabelle
    • LSR_BUKRS für eine lokal definierte Ranges-Workarea
  • SELECT-OPTIONS haben in der Regel einen Sonderstatus, weil ein Parameter im Selektionsbild (SELECT-OPTIONS und PARAMETER) nur acht Stellen haben darf (im Gegensatz zu Variablen, die 30 Stellen lang sein dürfen). Deswegen arbeite ich hier häufig mit S_BUKRS für SELECT-OPTIONS und P_BUKRS für PARAMETERS.
  • Die Definition mit RANGES ist inzwischen als obsolet gekennzeichnet, da eine implizite Workarea definiert wird. Eine Benennung im Typ nach Prefix ist also schwer, da es ein Tabellentyp und eine Struktur gleichzeitig ist.

Definition im Dictionary

Durch Zufall habe ich entdeckt, dass die Anlage von RANGES-Strukturen im Dictionary (Transaktion SE11) unterstützt wird. Folgend eine kleine Bilderserie, die die Anlage einer RANGES-Tabelle im Dictionary dokumentiert:

Aufruf Transaktion SE11 und Datentyp anlegen

2015-08-12_13-48-47

Auswahl Tabellentyp:

2015-08-12_13-49-15

Die Kurzbeschreibung füllen (Mussfeld!) und dann im Menü Bearbeiten • Als Ranges Tabellentyp definieren.

2015-08-12_14-26-04

Es erscheint ein anderes Dynpro und du kannst das Datenelement angeben, auf das sich die Rangestabelle beziehen soll:

2015-08-12_13-51-40

Den Namen des zugehörigen strukturierten Zeilentyps kannst du bereits angeben und durch Anlegen auch direkt anlegen lassen. Die notwendigen Felder werden bereits vorgegeben und du musst nur noch den Kurztext eingeben:

2015-08-12_13-54-32

Tipp

Die Ranges-Tabellen müssen nicht Typ-genau sein! Du kannst für den Datentyp BUKRS auch eine Ranges-Tabelle vom Typ CHAR10 definieren. Das referenzierte generische Datenelement muss natürlich entsprechend groß sein. Für die Verwendung mit der Materialnummer, die 18 Stellen lang ist, reicht CHAR10 selbstverständlich nicht aus.

Im Dictionary gibt es bereits ein paar generische RANGES-Tabellentypen, wie zum Beispiel

  • TAB_RANGE_C10
  • TAB_RANGE_C18

Oder entsprechende RANGES-Arbeitsbereiche:

  • RANGE_C10
  • RANGE_C18
  • RANGE_C50

Alternative

Statt den Tabellentyp im Dictionary zu definieren kann man auch einen einfacheren Weg gehen. In der Public section einer Klasse kann man globale Typen definieren. Also z.b. so:

TYPES: gty_bdter_range TYPE RANGE OF bdter .

Dieser Typ kann dann in der Signatur einer Methode direkt angegeben werden. Wenn die Sichtbarkeit der Klasse passt, kann der Typ sogar in anderen Klassen weiter verwendet werden.

Dann mit statischer Referenzierung, in dem Beispiel oben also:

TYPE zcl_myclass=>gty_bdter_range.

Mit diesem Vorgehen kann man dann ebenfalls Daten aus SELECT-OPTIONS in Reports direkt an Klassenmethoden übergeben.

Enno Wulff
Letzte Artikel von Enno Wulff (Alle anzeigen)